Current database Input/Output (“I/O”) systems (e.g., Oracle Database) consist of database writer processes, which make changes to one or more data volumes. Data volumes may be redundant (i.e., mirrored, RAID, etc.), although that kind of configuration detail is generally hidden behind some kind of a RAID controller or by operating system (“OS”) software, so that they appear as simple block devices to the database. Database systems also include one or more log writer processes, which write the database log, a record of changes to the data volumes. Change records in the log contain “before” and “after” images of changed fields as well as a record of all processed transactions. In most commercial database systems, the log is updated before any changes are made to the data volumes, a technique called “write ahead logging.” The log can be used to remove (undo) wrongly applied changes or re-apply (redo) any committed changes to the data volumes, in the event of transaction processing outages. The log may also be shipped to a remote backup system to enable remote replication of the database (for disaster tolerance), a technique known as “log shipping.”
Database systems must preserve committed transactions; therefore, they typically require that all log entries relating to a transaction be completely written to the log disk before the transaction can be committed. Disk writes are typically slow, often taking milliseconds to complete. Further, log records will rarely fit within an even number of disk blocks, so writing individual log records would require expensive read-modify-write operations. These factors would severely limit the database system's transaction processing rate if each transaction's log entry were written separately to disk. Therefore, database systems tend to buffer the log and write it out to disk only periodically. While such buffering makes better use of disk drives, it delays transaction commitment thereby negatively impacting the throughput of certain response-time-critical workloads.
Likewise, while “boxcarring” of multiple “user” transactions into a single “system” transaction can reduce the number of transactions that a system must track and commit, it has penalties in user response time, lock contention, and memory usage. Worse still, boxcarring complicates application recovery when system transactions abort, because multiple unrelated user transactions must be retried.